Enforce PKCE metadata compliance in OAuth client (#730)#1700
Open
PranavSenthilnathan wants to merge 2 commits into
Open
Conversation
…l#730) The OAuth client defaulted code_challenge_methods_supported to S256 when absent from authorization server metadata, masking non-compliant servers. Per the MCP 2025-11-25 spec, clients MUST verify PKCE support via metadata and refuse to proceed without it. Discovery now skips any well-known endpoint whose metadata omits PKCE support or lacks S256, falling through to the next endpoint (OAuth 2.0 vs OpenID Connect documents can differ), and fails only once all endpoints are exhausted. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
halter73
reviewed
Jul 16, 2026
| { | ||
| LogErrorFetchingAuthServerMetadata(ex, wellKnownEndpoint); | ||
| LogAuthServerMetadataMissingPkceSupport(ex, wellKnownEndpoint); | ||
| continue; |
Contributor
There was a problem hiding this comment.
If PRM is unavailable, don't we still reach BuildDefaultAuthServerMetadata here and synthesize S256? That would let metadata without code_challenge_methods_supported proceed through the legacy fallback. Can we limit that fallback to cases where no metadata document was found?
Previously, when PRM was unavailable, a discovered auth server metadata document that lacked 'code_challenge_methods_supported' would be skipped and the client would synthesize default metadata advertising S256, letting non-compliant servers proceed. Now the legacy default fallback only applies when no metadata document is discovered; a document that fails PKCE validation surfaces the specific failure instead. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 57bac4ff-fb62-4b33-88c3-342ce65e9d0a
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #730.
The OAuth client was defaulting
code_challenge_methods_supportedto["S256"]when it was absent from authorization server metadata:This masked non-compliant authorization servers. Per the MCP 2025-11-25 spec (and the current draft), clients MUST verify PKCE support via authorization server metadata and refuse to proceed if
code_challenge_methods_supportedis absent or doesn't advertiseS256.Changes
ClientOAuthProvider.GetAuthServerMetadataAsync: removed the["S256"]default. The discovery loop now validates PKCE support per endpoint. If a well-known document omitscode_challenge_methods_supportedor lacksS256, that endpoint is skipped and discovery falls through to the next one — different discovery mechanisms (OAuth 2.0 Authorization Server Metadata vs. OpenID Connect Discovery) can return different documents for the same server, and OIDC metadata commonly includes the field. Discovery fails only once all endpoints are exhausted, consistent with the existingauthorization_endpointfall-through behavior.tryblock with a dedicatedLogAuthServerMetadataMissingPkceSupportwarning, distinct from the generic metadata-fetch error log.BuildDefaultAuthServerMetadata, used when no protected-resource metadata is available) still synthesizesS256, so legacy servers without metadata discovery continue to work.Tests
CannotAuthenticate_WhenMetadataOmitsPkceMethods— metadata with nocode_challenge_methods_supportedis rejected.CannotAuthenticate_WhenMetadataLacksS256PkceMethod— metadata advertising onlyplainis rejected.CanAuthenticate_WhenFirstMetadataEndpointOmitsPkce_ButAnotherAdvertisesIt— when the OAuth 2.0 endpoint omits PKCE but the OpenID Connect document advertises it, the client falls through and authenticates successfully.CodeChallengeMethodsSupportedproperty and aMetadataPathsWithoutPkceSupportset to simulate endpoints with differing PKCE advertisement.All 46 OAuth
AuthTestspass on net8.0/net9.0/net10.0.Spec note
PKCE metadata verification was introduced in the 2025-11-25 spec; 2025-03-26 and 2025-06-18 required PKCE usage but not metadata verification. The current draft keeps the 2025-11-25 language unchanged.